1. Field of Use
The present invention relates to Internet applications and more specifically, to methods and systems for providing efficient communications between Web browser and server systems.
2. Description of Related Art
Significant changes are being made by companies in how they communicate with their customers and the types of services offered due to Web technology. One such change has been the use of a Web browser as a common front end to a mainframe or an enterprise system. In the case of IBM hosts, two basic methods have been utilized to give browsers access to such systems. These methods have been generically called native 3270 and Hypertext Markup Language (HTML) conversion. In the native 3270 method, a special browser is utilized that contains some form of built-in 3270 terminal emulator software and Java applets that know what to do with the 3270 data streams once they reach the desktop system. In the conversion method, 3270 formatted screens are converted into HTML format and posted to a Web server. The converted screens can then be viewed using any browser. These approaches are discussed in greater detail in an article entitled xe2x80x9cHow To Put Mainframes on the Webxe2x80x9d by Salvatore Salamone published in the June 1996 issue of Byte Magazine.
A disadvantage of the conversion approach is that it may not offer acceptable performance, throughput and response time in a high volume transaction environment. The reason is that the message is translated in a Web server extension and possibly in an intermediate application. Additionally, the message is forced to be routed through several applications and through intermediate applications. To overcome these disadvantages, one system employs an applet that supports mapping screen images associated with a transaction processing application to a modem, intuitive Graphical User Interface (GUI). This eliminates the need for intermediate message translation by having the browser application applet generate and process messages that are understood by the mainframe application. The applet also translates replies received from the application screen image format into a format that can be presented to and understood by the user. This approach is described in the copending patent application entitled xe2x80x9cMethod for Reducing Message Translation and Traffic Through Intermediate Applications and Systems in an Internet Applicationxe2x80x9d, Ser. No. 08/868,178, filed on Jun. 3, 1997 and assigned to the same assignee as named herein.
While the above approach improves performance by eliminating the need for intermediate message translation, it is specifically designed to operate with IBM mainframe hosts. Further, since the approach utilizes applets, it requires that the applet and HTML page be downloaded from a server over a non-persistent connection. The applet when executed within the browser is required to open a persistent connection back to the server. Hence, this approach necessitates the establishment of both persistent and non-persistent connections. Further, this approach still is quite time consuming and only performant when the ratio of persistent (applet to server) to non-persistent (HTML page and applet loading) traffic is high. However, even in those cases, the approach still requires that time be expended in establishing additional connections.
As well known in the art, in the classical client/server model, connections between client and application servers remain open until the client logs off the system. By contrast, in the Web environment, there is no mechanism provided for keeping the client-to-server connection open. Each time a new page is requested, the user, Web server and additional processing must reidentified or reinitialized. The reason is that the Web browser is xe2x80x9cstatelessxe2x80x9d. This xe2x80x9cstatelessnessxe2x80x9d makes it difficult to create Web-based applications requiring multiform client-to-server interactions.
In Web-enabled client/server tools, state and session is usually stored in client-side xe2x80x9ccookiexe2x80x9d files or hidden fields in HyperText Markup Language (HTML) forms. In Java application server environments, state and session management information is typically stored and managed on the server. Some server products make use of a xe2x80x9ccontextxe2x80x9d pool. When transactions are begun, the Web server generates a unique process identifier that is maintained with state information on the server in a xe2x80x9ccontextxe2x80x9d pool. Additionally, the process ID (or context ID) is embedded in the HTML passed along to the client, along with other state information. While state information may change during the course of a session, the process ID remains constant until the session terminates and the ID is discarded or returned to the context pool for reuse. These approaches can be viewed as server based approaches.
Another server based approach provides for retaining mainframe connection information on a web server that locates a user""s session when the browser reconnects and delivers the input to the mainframe application being run on the associated mainframe or legacy system. An example of this approach is the GWEB product developed by Gallagher and Robertson described at their website at http://www.gar.no/gweb/.
The combination of process IDs and storage of state information in a context pool is described in such server based approaches as allowing the execution environment of Java application servers to track the states of numerous clients connected to the Web server. In addition, it allows users to return to Web pages and view them in the state in which they left them. Further, it also ensures that a session is active during the user""s entire interaction with the application and keeps track of the state of the client""s interaction, as well as any transactions that are in progress, making it possible to commit and roll back operations. For a further discussion of Java application servers, reference may be made to the article entitled xe2x80x9cSelecting Java App Serversxe2x80x9d by Dan Kara published in the June 1998 issue of Object Magazine.
The above approaches place the burden on the server system to generate and manage the use of such state information. More importantly, since the use of such state information does not control the establishment of connections, it does not necessarily reduce the traffic on the particular internetwork over which client and server systems communicate.
To reduce traffic, another prior art system makes an on-line transaction processing system accessible to Web browsers by establishing a predetermined plurality of transaction gateway clients to receive HTTP requests that are received by a Web server from the Web browsers. Concurrent processing of multiple transaction requests from the Web browsers is performed by the plurality of transaction gateway clients. Each transaction gateway client pre-establishes a static connection with the on-line transaction processing system. The pre-established connection allows requests from the Web browsers to be quickly routed to the transaction processing system. The gateway client translates between HTTP formatted requests from the Web browsers and the request format expected by the on-line transaction processing system. This system is described in further detail, in U.S. Pat. No. 5,754,772 that issued on May 19, 1998.
While the system provides access to a mainframe host, the system has to be able to pre-allocate the required number of static connections and gateway clients beforehand making it more difficult for the system to respond to dynamic changes in operations. Further, the system must expend time in translating requests into the format expected by the on-line transaction processing system.
Another relevant prior art approach utilizes a server and a web browser terminal emulator for providing a persistent connection to a legacy host system. A computer network environment allows connection of a client system to a legacy host system using such a server system. The server system executes a client thread under a server. The client thread is operable to communicate with the legacy host system across a persistent TCP/IP socket connection. The computer network environment further includes a client system executing an applet process under a web server. The applet process is operable to communicate with the client thread across another persistent TCP/IP socket connection and is operable to provide a terminal session to a user of the client system. This approach is described in U.S. Pat. No. 5,754,830 issued on May 19, 1998. The main disadvantages of this approach pertain to requiring the loading of an applet and the inclusion of a web/emulation server.
Web browser software is well known in the art for use in retrieving and viewing electronic documents in HTML format from part of the xe2x80x9cInternetxe2x80x9d known as the xe2x80x9cworld-wide webxe2x80x9d. The World Wide Web part of the Internet is a collection of server computers (i.e., sites) on the Internet, which store HTML documents that can be publicly accessed by computer users connected to the Internet. HTML documents include as a subset, xe2x80x9cformsxe2x80x9d that allow the user to supply information. Thus, a server system (form provider) can use forms to collect information and to provide back and forth interaction. The use of forms is discussed in the text entitled, xe2x80x9cCGI Programming on the World Wide Web,xe2x80x9d by Shishir Gundavaram, Copyright(copyright)1996, O""Reilly and Associates, Inc.
As known in the art, HTML documents on the World Wide Web often contain several thousands of bytes and often incorporate several image/graphic files representative of forms, each of which also contain thousands of bytes. At the current transfer speeds used to connect to the Internet, the transmission of such forms can take considerable time (e.g. seconds to minutes) to complete downloading from a computer site.
In some prior art enterprise systems, so-called xe2x80x9cremote forms packagesxe2x80x9d have been used for terminal based applications to make form processing more time efficient. An example of two such packages are the Transaction Processor Forms Facility (TPFF) product and the Transaction Screen Management System 8 (TSM) product developed and marketed by Bull HN Information Systems Inc. Information about these software products may be found in the Bull publications entitled xe2x80x9cTransaction Processing TPFF System Software Release Bulletin, Software Release 8FO1.0, Update 5 GCOS 8xe2x80x9d, order number 67 A2 SA65 Rev05, dated March, 1993 and xe2x80x9cTools and Utilities Transaction Screen Management System 8, TSM8 Reference Manual GCOS 8, order number 67 A2 ED42 Rev02, Dated March 1995.
These packages provide functionality that enables a remote forms mechanism (e.g. TSM8) to create a forms directory for a terminal user as required and also a subdirectory for every unique xe2x80x9cconnect namexe2x80x9d (e.g., TSMTP8). This avoids needless retransmission of forms where form versions are not synchronized among multiple TSM8 installations. Using a co-operative TSM8 local forms storage protocol, the enterprise system connected to the terminal transmits the required forms for a particular user once. The forms received by the terminal are stored on a local storage device for later use. When a terminal user desires access to a form, this causes the generation of a form mount request to the local storage device that results in the display of the requested form on the user""s terminal.
As known in the art, there are systems that provide for the remote retrieval and display management of electronic documents with incorporated images. These systems are able to provide both static and variable data associated with form documents. Examples of systems that provide for the remote retrieval and display management of electronic documents and for using a dialog session context to process electronic forms data are described in U.S. Pat. Nos. 5,778,372 and 5,784,562, respectively. It has been noted that typically, the static portion of such responses are high in data content and the repetitious transmission of this data content for multiple requests can be an inefficient use of bandwidth.
Thus, the above prior art approaches have not been able to achieve the same levels of network performance in processing HTML based forms as heretofore provided to users accustomed to using terminals with remote forms facilities. An important aspect of the present invention is its recognition of the need for a high performance solution that implements a remote forms capability heretofore provided by enterprise systems that can be utilized with standard browser software.
Web browser software utilizes a standard application communications protocol such as the HyperText Transport Protocol (HTTP) for processing HTML formatted documents. A number of vendor enterprise systems do not normally process HTML formatted documents and execute HTTP server programs. By contrast, such systems normally execute transactions using their own unique proprietary protocols (e.g. DSA, SNA) specifically designed for their particular applications in contrast to using a standard internet communications protocol such as TCP/IP. Recently, some vendors have implemented the RFC1006 specification that defines a protocol layer that closely resembles the OSI transport layer and runs on TCP/IP. By implementing such a layer, a proprietary protocol like DSA, developed by Bull HN Information Systems Inc., is allowed to run over a TCP/IP network.
While the above capability is available, there is still need to provide an efficient way of connecting to enterprise systems that operate with different communications protocols.
Accordingly, it is an object of the present invention to make communications sessions between a Web browser and a server persistent without having to utilize static connections.
It is a further object of the present invention to provide access to transaction applications running on a server system without having to reformat Web browser pages or alter use of existing protocols.
It is still a further object of the present invention to provide fast efficient transaction conversations for transferring various kinds of data messages.
Accordingly, it is another object of the present invention to provide a remote forms facility that operates in conjunction with standard browser software that is easy to manage by a browser user.
It is a further object of the present invention to provide a remote forms capability characterized by high performance and not having to reformat Web browser pages or alter use of existing protocols.
It is another object of the present invention to provide a facility for connecting to server systems that utilize different communications protocols.
The above objects are achieved in a preferred embodiment of the present invention for processing requests generated by a user of a client system for accessing facilities of a server system through a communications network. The client system includes a high performance gateway component that operates in conjunction with a standard browser component. In the preferred embodiment, the gateway component is installed on the same client system or on a client workstation system. The gateway
Component manages the establishment of persistent sessions in response to client requests and maintains information uniquely identifying existing persistent session connections opened between the client system and the server system.
In accordance with the present invention, the client side capabilities are enhanced through the inclusion of such a gateway component. The gateway component operatively couples to the standard browser component through a standard browser interface. More specifically, the browser component and gateway component communicate using standard HTTP protocols over a standard browser interface. The gateway component operatively couples to the server system through an internetwork (e.g. Internet). In the preferred embodiment, the gateway component communicates with the server system through several layers of protocols to obviate the need to develop additional protocol software for running existing server applications. The protocols used in the preferred embodiment are HTTP, DSA and TCP/IP.
According to the teachings of the present invention, the browser component initiates the utilization of new session connections and reuse of existing session connections through an uniquely coded universal resource locator (URL) contained in each issued request. Each URL is passed to the gateway component that examines a context field included within the URL. If the context field has been set to a first value, the gateway component opens a new session connection to the server system and records the session information as an entry in a persistent session table (PST) component maintained by the gateway component. If the context field has been set to a value other than the first value, then the gateway component obtains the session information in the PST component for the established session and passes the data from the browser component to the server system over the existing session connection.
In the preferred embodiment, the server system""s response to an initial request from the gateway component following the establishment of the new persistent connection generates a HTML page with a BASE tag value and also communicates the base value to the gateway component which stores it as part of the PST entry. Relative links in the new HTML page, when activated, are built by the browser incorporating the new BASE value which results in a URL containing the new base value being used on any subsequent requests which uses these links. The BASE value in the URL enables the gateway component to locate the connection, which enables the use of an established persistent connection throughout a session.
The arrangement of the present invention improves system performance by providing xe2x80x9cclient sidexe2x80x9d dynamically controlled persistent connections. This eliminates the need to continuously establish new sessions each time the xe2x80x9cstatelessxe2x80x9d browser component initiates a request. Further, the invention accomplishes this by extending the functionality of the client system by the addition of the gateway component thereby relieving the server system from the burden of having to establish and control persistent connections. Further, the arrangement of the present invention enables the use of persistent connections for transferring data messages other than forms in that the connection information is preserved by the gateway component until the client system has terminated a particular session. Of course, it will be appreciated that when a particular session connection is being utilized by more than one client browser user as described herein, the gateway component retains the connection information until all browser users have completed their respective sessions.
In accordance with the teachings of the present invention, the gateway component of the preferred embodiment may also include the capability of enabling use of xe2x80x9csession poolsxe2x80x9d. When the gateway component includes this capability, a plurality of persistent sessions connections are initially established. This allows the gateway component to immediately connect a browser component to a server system in response to a browser request having a URL specifying a new session connection. The result is improved performance.
Also in accordance with the teachings of the present invention, the gateway component may also include the capability of enabling multiplexing persistent session connections for servicing a plurality of browser requests generated during a number of different user sessions. This capability enables several browser users or a single browser user to conduct multiple sessions over a single shared persistent session connection. An advantage of such a capability is an improvement in processing efficiency in handling a high volume of user requests with a limited number of connections.
In accordance with the teachings of the present invention, the above capabilities are invoked by the browser component by the same basic URL mechanism. The URL of the preferred embodiment may include an optional field portion that enables a user to select either capability or elect not to use a capability in a given situation. For example, a user may elect not to enable the multiplexing capability because of not wanting to share a common persistent connection for reasons of maintaining security.
In addition to the above, the gateway component of the present invention includes facilities that enable a browser user to communicate with a particular enterprise server system using any one of a number of predefined communications protocols (e.g. DSA, SNA) based on the requirements of the particular system. In accordance with the teachings of the present invention, the basic URL mechanism is used to enable user selection of a particular communications protocol.
Also in accordance with the teachings of the present invention, the gateway component of the preferred embodiment of the present invention includes a remote forms mechanism that enables storage of the static portion of a message that is local to a Web browser client system so that only variable data needs to be transmitted from a server to the browser client system. As used herein, the term xe2x80x9cremote formxe2x80x9d refers to the static portion of an HTML page. The mechanism provides local storage in the form of a cache component for retaining the static portions of a plurality of forms in close proximity to the client user. If the remote form is present in the cache component, the gateway component reads the form and merges it with the data returned from the server in its response. The gateway component then forwards the merged data to the browser for display to the user.
If the remote form is not present in the local cache, the gateway component will make a request to the server for a copy of the form. When the form is received from the server, the gateway component will write it to its cache. The gateway component will then merge the form with the data previously received and forward it to the browser for display to the user.
The gateway component of the present invention requires no changes to the standard browser system. For example, the gateway component in the preferred embodiment is implemented as a plurality of class objects that can run on the virtual machine included as part of the standard browser and utilize standard Java library routines for establishing and maintaining persistent connections. Hence, the present invention is able to maximize the use of capabilities included with a standard browser.
Further, the present invention enhances performance by coding all of the pertinent connection information and any available options into the URL. This avoids unnecessary scanning operations for detecting xe2x80x9ccookiesxe2x80x9d in HTTP headers and hidden form fields in HTML document pages. In addition, since the URL does not point to an actual file system directory, it is possible to have a unique URL for every persistent connection. Thus, the gateway component is able to maintain persistent connections while at the same time conforming to the requirements of the HTTP stateless protocol.
It will be noted that the term xe2x80x9cgatewayxe2x80x9d has been used in referring to the access mechanism of the present invention. In accordance with the teachings of the present invention, the term xe2x80x9cgatewayxe2x80x9d is used in the broad sense to refer to a software component that is installable on a standard personal computer or workstation rather than on a separate or immediate server system, such as a Web or HTTP server system.